What

Adds getActiveEnv(), which resolves the active environment at runtime from the
PLAYGROUND_ENV env var (validated against CONFIGS, trimmed), falling back to the
build-time DEFAULT_ENV. getChainConfig(), getNetworkLabel(), getTokenSymbol(),
and getPgasAssetId() now default to it instead of DEFAULT_ENV.

Why

Today ACTIVE_TESTNET_ENV is the only network switch, and the direct-chain layer
(getConnection, pairing, registry, drip — every no-arg getChainConfig() reader) is
pinned to DEFAULT_ENV. runDeploy({ env }) reroutes the deploy legs, but the
direct-chain reads can't follow it, so a host that wants to deploy to a non-default
wired env (e.g. deploying to Summit from a Paseo-default build) ends up split-brain:
storage/DotNS on one chain, funding/identity/registry on another.

Resolving the active env from PLAYGROUND_ENV lets a single build point its own reads
at any wired env at runtime — no rebuild, no ACTIVE_TESTNET_ENV flip. The motivating
consumer is the RevX deploy runner, which sets PLAYGROUND_ENV per container from the
user's selected network.

Behaviour / compatibility

• Non-breaking, opt-in. With PLAYGROUND_ENV unset, behaviour is byte-identical to
  before (getActiveEnv() → DEFAULT_ENV). Function signatures are unchanged; only the
  default-param source changed, so explicit-env callers (every command) are unaffected.
• Unknown / whitespace PLAYGROUND_ENV values fall back to DEFAULT_ENV.

Tests

src/config.test.ts covers: unset → DEFAULT_ENV, a wired value, surrounding whitespace
trimmed, garbage → fallback, and that the no-arg config + display helpers thread through
the override.